🧙 Sourcery has finished reviewing your pull request!

@l r

Alright, first things first— you added libdisplay-info to the Arch container package list inside the ci.yml. Fine, but what's the big deal? It's probably a new dependency you just needed for some feature or fix, right? I get it, sure, but let me roast a bit and then drop some diagrams.

Roast Time:

• You creators of this pipeline seem to ONLY test this on Arch Linux container but push on Ubuntu-latest runners? What if Arch-specific packages break your app on Ubuntu-native? You should test on both. Having just one exotic container environment is code quality harakiri.
• Adding a dependency in the CI is fine, but where is the documentation or version pinning? Arch can be bleeding edge — constantly updating packages. You’re risking nondeterministic builds — a classic recipe for flaky CI. Don't forget reproducibility.
• You run pacman -Syu without a cache or locking mechanism or version pinning. That's gonna lengthen CI substantially and make build results non-repeatable.
• You run rm -rf /host/usr/local/lib/android with no explanation or validation. What if somebody actually needed that? Chaos ensues.
• The comment about "safe directory issues" is probably copy-paste evil, but at least you linked an issue. Ok, points for that.
• This PR touches only the CI environment setup with a tiny dependency add; zero tests or verification steps added. You should embrace the power of automation and test at least that the package was installed or can be called successfully.
• The overall pipeline seems very monolithic. A mega CI job with a massive container that bundles everything? Smells like legacy monolithic tech debt and zero component isolation. Breaking this into smaller jobs/tests would speed things up and reduce blast radius on failures.

Current repo pipeline workflow (very simplified)

flowchart TD
    A["Host runner: ubuntu-latest"] --> B["Container: archlinux:latest"]
    B --> C["Run pacman update + install packages"]
    C --> D["Clean android libs: rm -rf /host/usr/local/lib/android"]
    D --> E["actions/checkout@v3 with recursive submodules"]
    E --> F["Git config safe.directory '*'"]
    F --> G["Run build script: just sysext"]

PR Change visualization

flowchart TD
    subgraph "PR Added Dependency"
        C -->|Added package| C_libdisplay["libdisplay-info"]
    end

Tech Debt & Improvement Roadmap

flowchart TD
    A["Monolithic CI job"] --> B["Slow builds / flakiness due to up-to-date Arch updates"]
    B --> C["Undocumented + unpinned dependencies"]
    C --> D["Non reproducible builds -> hard to debug"]
    D --> E["Fragile CI, inconsistent dev envs"]

    subgraph Improvements
        I1["Split tests into multiple jobs based on concerns (build, test, lint)"]
        I2["Use pinned package versions or container snapshots"]
        I3["Add verification steps for dependencies installed"]
        I4["Document dependencies, reasons, and keep changelog"]
        I5["Cache pacman package downloads + rely on minimal base images"]
        I6["Add Ubuntu-based test matrix alongside Arch"]
    end

    E --> Improvements
    Improvements -.-> A

Summary: Your PR content is super tiny, just an addition of a package install in the CI Arch container environment. It’s not wrong per se, but it’s a sign of a very fragile and bleeding-edge monolithic pipeline that will cause headaches down the road. Add better documentation, pin your dependencies, and start modularizing the CI jobs so each part can fail fast and independently. Stop relying on bleeding-edge Arch as your one and only CI environment. Also, clean up those cryptic commands like removing android libs without context.

Fix that, and maybe some of the build gods will smile upon you. Otherwise, keep adding random packages and watch your CI falter hilariously on random days.